Minutes, IBIS Quality Task Group

21 September 2021

12:00-13:00 EST (09:00-10:00 PST)

ROLL CALL

ANSYS                               Curtis Clark
Intel Technology                    Michael Mirmak
Micron Technology                 * Randy Wolff
Signal Integrity Software:        * Mike LaBonte
Teraspeed Labs:                   * Bob Ross
Zuken USA:                        * Lance Wang

Everyone in attendance marked by *

NOTE: "AR" = Action Required.

-----------------------MINUTES ---------------------------
Mike LaBonte conducted the meeting.

Call for IBIS related patent disclosures:

- None


Call for opens:

- Mike LaBonte said we were requested in a prior Open Forum meeting to discuss the details
  of checking Aggressor_Only status in [Interconnect Model]s..


Review of previous meeting minutes:
Minutes from the September 14, 2021 meeting were reviewed. Randy Wolff moved to accept the
minutes.  Lance Wang seconded. Without objection, the minutes were approved.


ARs:
- AR: Bob Ross to review QA suite results for IBISCHK710
  Note done yet.
- AR: Mike LaBonte to test first IBISCHK710 code drop
  Done.


NEW ITEMS:

New parser bug reports:
Bob Ross reported there were no new bug reports.


IBISCHK710 development:
Bob Ross showed questions from the IBISCHK developer.  One question was about numeric
scaling suffixes. Bob said they should be checked for validity.  Randy Wolff asked if
those were IBIS parameters or IBIS-ISS parameters. Bob said they were IBIS-ISS.  Randy
said they would be found on the .subckt statements then.  Bob said IBIS allowed an "A"
suffix to mean amperes, whereas in SPICE it denoted "atto".

A second question was if the "=" was required for variable references. Bob and Randy
agreed it was.  For example, "y" in a terminal list would not be interpreted as "y=".
Randy said a terminal line could have both "y" and "y=1". The first one would be a
terminal name, and the second a variable assignment.  Bob said variable names that
appeared in assignment expressions did not require a default value.  Mike LaBonte said
that seemed like an implicit variable declaration.  Lance Wang said HSPICE allowed "y=y",
which would explicitly declare the variable without giving a default.  Mike felt it would
have to be an error if "z" in "y=3+z" was not defined anywhere.  We agreed that would have
to be an error.  Mike said it might be possible to override an expression with an instance
value.  Randy said expressions could not be defined on .subckt statements, they had to be
in .param statements.  Lance suggested disallowing expressions in .subckt statements.
Randy said IBIS allowed "variable=value" on .subckt statements, but the syntax for "value"
was not further defined.  Bob said he would send our decisions to the developer.  Mike
said it made sense that equations would be found in .param, inside or outside a subckt.
Randy said IBIS-ISS did allow .param statements outside subckts.  Mike asked if it would
be an error for a subckt call to specify a parameter that was not defined on the .subckt
statement.  Randy said there should be a warning that a passed parameter was not used.

Bob said the IBISCHK710 development contract called for handling expressions in .subckt
statements, but that was a mistake.  He showed a contract page with a syntax example that
had "c='a+b'" on a .subckt statement.  Lance asked if "a" and "b" could be global. Randy
said yes. Lance said we had no way in IBIS-ISS to declare global variables.  Randy said
they always had to be passed in instance calls.  Bob enumerated four places in IBIS where
instance parameters were passed.  Randy said IBIS would not allow "a=a", even if HSPICE
would.

Aggressor_Only:
Mike noted that the developer question about whether a single [Interconnect Model] with
all Aggressor_Only paths should have a warning was discussed in the prior Open Forum
meeting, and Randy Wolff had suggested continuing in this meeting.  Bob said it was
possible to have Aggressor_Only for pins 1 and 2 on one [Interconnect Model], but pins 1,
2, 3, and 4 were part of another connected [Interconnect Model].  He said Arpad Muranyi's
Open Forum comment was correct, but we should allow it because we allowed cascaded paths.

Bob described [Interconnect Model Group]s and [interconnect Model Set]s.  Mike said two
[Interconnect Model]s having paths with the same pin name may or may not be cascaded
together at circuit building time.  Bob suggested models should be checked only at the
[Interconnect Model Group] level.  Mike felt there was no way to know what would be
connected, and we should not check for such.  Randy agreed, adding that [Interconnect
Model]s did not really declare whether coupling was modeled.

Bob said we should allow contradictory pin I/O paths among sets.  He said the models in an
[Interconnect Model Group] would be flattened, and pin names would be used to determine
that.  Mike said a use case for [interconnect Model Set]s was where one had uncoupled
models and another would have coupled models, for the same pins.  He said a tool might
select only one of those at a time.  Randy said there was no assured way to predict the
connections that would appear in a simulation circuit.

Randy noted that the developer question was about whether a single [Interconnect Model]
with all Aggressor_Only paths should have a warning.  We agreed it should.


Tabled topics (no discussion without motion):
  - BIRD181.2
  - IBISCHK security fixes

AR: Bob Ross to reply to IBISCHK developer questions


Randy Wolff moved to adjourn. Lance Wang seconded. Without objection the meeting ended.

Meeting ended: 13:13 ET

Next meeting September 28, 2021